Archive Magazine CD 1995

home *** CD-ROM | disk | FTP | other *** search

/ Archive Magazine CD 1995 / Archive Magazine CD 1995.iso / discs / utilities / utility_04 / changefsi / !ChangeFSI / FSIinfo < prev next >

Wrap

Text File | 1992-05-11 | 49.2 KB | 963 lines

ChangeFSI: Colour Image Processing Using the 256 colour modes Archimedes computers have full colour display capabilities built into them as standard. However, compared with the hardware found in larger workstations, the facilities provided have been carefully reduced (in order to make them cheap enough to fit all the time). So the precision of the digital to analogue converters is only 4 bits (instead of 8) and the colour palette only has 16 entries (instead of 256). The VIDC 256 colour mode ========================= Has 4 direct bits (top 2 green, top red and blue) plus 4 palette look up bits which affect the remaining DAC bits. This therefore gives a choice of 256 colours from 4096, but the choice is not a free one in that the 4 direct bits are always connected: this leaves only 256 selections available from the 4096 colour range. To repeat: there are 256 simultaneous colours in a selection out of 4096 colours, where there are only 256 "legal" selections. There are "optimal" selections. An optimal selection is one which covers the entire R, G, B colour cube (i.e. 0-fullscale for each of the colours) and can thus be dithered to from any picture (if one considers picture's colour range as an arbitrary volume in the colour cube, then you can dither/display a picture accurately if and only if the volume covered by the available colours encloses the picture's). The optimal selection used for the RISC OS 256 colour mode palette contains 2 most significant bits of Red, 2 most significant bits of Green and 2 most significant bits of Blue, with the last 2 bits controlling the 2 least significant bits in parallel ("adds white" to a colour). Thus peak R, G, B is obtained (without side effects if varied simultaneously, with a side effect if peak R (say) alone is required). A correctly designed error diffusion dither algorithm can display pictures with very high fidelity. [note that dithering all pictures with a single palette permits their display simultaneously on the screen, also note that dithering to a fixed palette is much quicker than selecting a palette first!] One can also program the system for a large number of n bits per colour modes, with the n bits starting at the most significant end of the colour range. For example 4 bits of green, 3 bits of red and 1 bit of blue. The constraints are: 2 <= nGreen <= 4 1 <= nRed <= 4 1 <= nBlue <= 4 (and nRed+nBlue+nGreen=8) Modes like these are often useful for real time solid modelling (where the expense of dithering with error diffusion (circa 100 cycles per pixel) cannot be afforded). These selections are non-optimal: the colour cube is not completely spanned. Displaying A Picture ==================== Since a colour in the 256 colour mode can be such a complicated thing, with varying capability of spanning the colour cube and an unknown accuracy, there is a RISC OS standard way of specifying a colour you wish to draw with using 8 bits for R, G and B components. A call to the operating system converts this to the nearest colour and new objects can be drawn. Where the object to be drawn is a previously generated picture, the modules "SpriteExtend" (in the ROM) and "ColourTrans" (in the !System directory) in RISC OS provide some capabilites for displaying pictures in different screen modes. ColourTrans can look at the palette which a sprite uses and return a list of the equivalent 'closest' colours in the current screen mode. SpriteExtend can paint sprites using the list of equivalent colours and can change the size of the image into the bargain. This is all very well for simple pictures or pictures created directly for a particular mode, but what happens for more detailed information or pictures from other sources with resolution not matched by the Archimedes hardware? Also the above facilities are rather basic: ColourTrans makes no effort to use dithering (the practise of putting patterns of different coloured pixels together to represent other colours) and SpriteExtend simply discards additional information if reducing the picture in size (and together they make no attempt to enhance the picture when making it larger). The reason for these shortcomings is quite simple: speed. The algorithm used in ChangeFSI uses 105 ARM instructions per pixel - and that's apart from any instructions used to read the image in, change its size and write the result out. For comparison, the normal sprite plot takes only one instruction per pixel (4 instructions for four 8 bit pixels). Processing a MODE 15 picture thus uses up too many seconds of ARM cpu time to imagine it as part of the interactive desktop. So what does ChangeFSI do to make the situation better? And why does it take so long? One can immediately draw up some desirable properties for any solution to the image changing problem: (1) Maximising the volume of the colour cube. Colour represented in the Red, Green and Blue computer graphics system can be thought of as a point in a 3D cube whose axes are the red, green and blue values. Whatever clever approximations, dithering or error diffusion techniques are used, the colour volume spanned by the r, g and b axes in the target should be large enough to contain the source volume. If not, then the picture will appear faded in some way compared to the original ("the red doesn't seem quite the same"). For a single picture a colour volume only as large as the input could be chosen; alternatively for an arbitrary set of input pictures, the colour volume on the output system has to be made as large as possible. Where animation is required the colour volume has to be consistent for all the pictures. When generating the largest volume, it is important to use the system hardware to the limit: for example, if one has two bits of control over the Archimedes 4 bit D to A converters, the largest range is covered by values 0, 5, 10 and 15 (rather than 0, 4, 8 and 12). (2) Giving hue consistency at different saturations. For example, with a palette with different numbers of bits of r, g and b it may be impossible to have a consistent set of colours representing derived colours at different levels of intensity. Shades of white and secondary colours (cyan, magenta and yellow) are particularly difficult. (3) Working with the multi-tasking desktop. Acorn are asking for all new software to be built on the multitasking system. This implies that the palette should not be changed (or that the agreement of all programs currently running is obtained first). The desktop (default) palette in the 256 colour modes (e.g. modes 13, 15, 21, 24 and 28) is quite well designed. It does have the properties of (1) and (2) (it even has 16 shades of grey) and automatically satisfies (3). It is used by many Acorn programs (Draw, Paint) and by external programs (Euclid, ProArtisan, Atelier, ..) to great effect and is a safe choice for ChangeFSI. There are three ways ChangeFSI can choose a colour: (a) a method which derives values for r, g, b and tint algorithmically (no suffix) (suitable only for the default RISC OS 256 colour palette) (b) search the palette for the closest colour (r suffix) (slow!) (c) a 4096 entry table indexed by r, g and b which gives the answer (t suffix) ASIDE: the closest colour is chosen such that the distance between the true colour and the choice is minimised in the colour cube space. Since the human eye is more sensitive to green, then red and lastly blue, the distance function is weighted 10, 3 and 1 in green's favour. With the 16 colour modes (e.g. modes 9, 12, 16, 20 and 27) the default palette does not satisfy (1) and (2) unless the output is purely shades of grey - ChangeFSI can use either 8 greys (for the desktop) or 16 greys (out of the desktop or with the desktop palette altered to provide 16 greys). For colour representation, ChangeFSI can either: (a) use 1 bit of red, 1 bit of green and 1 bit of blue (i.e. the standard 8 digital colours Black, Red, Green, Blue, Yellow, Magenta, Cyan and White). This spans the colour cube and is hue consistent, but doesn't use the full range of bits provided in the format. ColourTrans can map this to the desktop with the standard palette with fair success, except for the lack of magenta (full red+full blue) in the palette. A better result can be achieved by setting 6 of the colours in the palette to red, green, yellow, blue, magenta and cyan. Since ColourTrans will map the colours anyway, it doesn't matter which 6, but the most consistent values are 8=blue, 9=yellow, 10=green, 11=red, 13=cyan, 14=magenta (leaving 0-7, 12 and 15 unchanged). This option is selected by a "d" (digital RGB) suffix to the program's mode argument. or (b) search the palette for the closest colour (r suffix) [ChangeFSI needs to be in the 16 colour mode in order to read the palette] With the 4 colour modes (e.g. modes 8, 11, 19 and 26) ChangeFSI is really pushed. Shades of grey output is done with the 0, 5, 10, 15 level palette. But how can colour be done? For example, each pixel can display only one of (say) black, red, green or blue. This fails to span the colour cube (it does only half of it), however, so black, cyan, magenta and yellow are used instead. The rest has to be left to luck: there is no way it can approximate to pure shades of red, green or blue. 4 bit colour pictures can be seen on the desktop in 16 colour modes with the above palette or in 256 colour modes. This option is by a "c" suffix. If you can provide a better palette, then ChangeFSI can use it with the "r" suffix search method. With 2 colour modes (e.g. modes 0, 18, 23 and 25) pixels are either ON or OFF, ChangeFSI will only do shades of grey output.... However, the method used can be varied (see later). So that's the canvas ChangeFSI has to work on. How does it display the input range of colours on these outputs? The answer is, as stated above, dithering: the process of approximating intensity variations with patterned areas. There are two basic types of dithering technique: that used to print colour magazines and newspaper photographs "clustered dot dither" - the size of the dot of ink gives the intensity; and that used on dot matrix displays, for example the grey level patterns used by 1 bit per pixel mode on the desktop "dispersed dot dither" where the average number of dots in the area gives the intensity. Why does the world need two different techniques? Well, different devices reproduce pixels differently. The "ideal square" pixels produced by an LCD are perfect for dispersed dot dither; a CRT produces a gaussian spot (a circle or ellipse which decays in intensity towards the edges) instead of a square - dispersed dot dither works well; a dot matrix impact printer or a "write black" laser printer produce large dots (diameter at least SQR(2) over unit pixel square) and thus make pictures too dark if dispersed dot dither is used; a "write white" laser printer prints negative "white dots" on a black field and thus "caves in" the sides of pixels making pictures too white with dispersed dot dither. Clustered dot dither reduces the effects of mis-sized pixels by ensuring they are adjacent (and thus the error is confined to the periphery of the shape) but this does have a cost in poorer resolution. Since ChangeFSI's colour or greyscale output is to CRTs (or LCDs in some distant future) it automatically uses a dispersed dot dither. Monochrome output could be for the screen or for a printer: the user can select between dispersed and clustered methods by adding a various suffices ("c", "d" or "t") to the mode number for clustered output. For "c" the algorithm (due to Robert L Gard, 1976) approximates tones in the range 0..16 (17 levels) by using 0..16 "on" pixels in a 4 by 4 cell. For "d" the algorithm (developed by me, but similar to Gard's) approximates tones in the range 0..4 (5 levels) by using 0..4 "on" pixels in a 2 by 2 cell. For "t" the algorithm (ditto as "d") approximates tones in the range 0..9 (10 levels) by using 0..9 "on" pixels in a 3 by 3 cell. The "on" pixels are carefully chosen to provide: (a) symmetry of white/black and black/white patterns (b) diagonally oriented dot grid. The diagonal angle reduces the eye's ability to see the rectangular patterns produced. The various sizes of the halftone cell allow some trade off between representing the tonal values correctly and loss of resolution. Start with "c" and progress to "t" and then "d" if the resolution is not acceptable. ChangeFSI can generate reasonable pictures on "write black" printers with a dispersed dot dither by using the "-black" parameter; however images produced like this do not photocopy at all well (the photocopier makes the dots blacker again!). The parameter to -black (default value 32, range 0..128) tells ChangeFSI how much larger than the ideal square pixel the dots produced by the printer are - 128 corresponds to an inked dot covering four times the area of the ideal black square pixel (and this will generally mean ChangeFSI produces an entirely white output!). Values above 64 give rather poor results on some pictures but may be worth experimenting with. The default is 32, a dot covering 50% more area than the square pixel (the minimum circle enclosing the pixel square). Some printers produce dots of (pseudo-randomly) varying sizes and black correction may not help with these (the picture looks "noisy") in which case use one of the clustered output methods. -black correction makes pictures on the screen look very pale, since, if anything, black pixels on screen are smaller than the ideal square. [aside: to print these pictures, you need a method which copies the pixels ChangeFSI has made exactly to those of the output device. Using !Paint, scale X and Y by 90:300 for a 300dpi printer.] In all cases, an approximation to a colour will produce an error (which might possibly be zero if ChangeFSI is very lucky). ChangeFSI tracks these errors and ensures that over wide areas there is no overall error using a technique called "error diffusion", first devised by R W Floyd and L Steinberg in 1975. In this technique the approximation is made and the error distributed to nearby pixels in the following ratios: current pixel 7/16 of error 3/16 of error 5/16 of error 1/16 of error ChangeFSI gets some of its name from Floyd and Steinberg. Additionally, ChangeFSI scans through the picture in a serpentine fashion, doing a row of pixels left to right followed by the next row right to left. This reduces the probability of regular patterns which the eye is sensitive to. The final I of the name is for Integer: ChangeFSI does all its work in 32 bit fixed point integer arithmetic (with the point at bit 28) instead of floating point. Dithering can be turned off using using "Disable Dithering" on the Processing dialogue ("-nodither" on the command line) which at least allows you to see how well it does! The conversion from one colour range to another is made at the same time as a change in size of the image. Size is changed by ratios of areas between the input and output: the total weight of r, g, and b in the source area is calculated using the fixed point arithmetic and this result is then approximated to the output using the error diffusion to preserve information (for example, consider halving in size an image with adjacent pixels of intensities 1 and 2; the output pixel needs to be value 1.5, so the 0.5 error is sent to adjacent pixels to keep the overall colour the same). The size change is expressed as a ratio of output to input (e.g. 40:20) which ChangeFSI reduces to the smallest possible terms (2:1 in this case) so that you are free to give values like 256:512 if that's what you mean! Size change is either both x and y (if one ratio is given) or separate x and y (if two ratios are given). Note that the size of a RISC OS pixel is known, so changing from (say) mode 21 to (say) mode 13 does not need any additional specified scaling. The full size output for mode 21 is the reference, so scale to 640 by 512. A common scaling is to fill the output sprite with the input and an "=" parameter to x and/or y ratios will do this without ever having to know the size of the input. Simply omitting the fractional part causes ChangeFSI to put in the source size, thus giving output which is the specified number of pixels in size. Conversion from colour to monochrome shades of grey is done with the CIE luminance weights for r, g and b (0.299, 0.587, 0.114) which is the standard conversion for broadcast television. These values can be altered using the -red, -green and -blue commands and allow different weightings for conversion to monochrome to be tried, this also allows selection of an image composed of only some of the colours (e.g. -red1 -green0 -blue0) in making a black and white image. ChangeFSI can take any RISC OS sprites (2, 4, 16 or 256 colours). If there is a palette it will be used, otherwise the standard 2, 4, 16 and 256 colour desktop palettes are used. ChangeFSI is both a command line driven program and a desktop application. The file !Help describes how to use the application from the desktop, if you need to use the program as a command line driven program you will need to have it in the library (or on run$path) and press f12 to get out of the desktop. The file "FSIuse" describes the parameters concisely. The program selects mode 0 when run from the command line when doing any work in order to speed up processing (this can be disabled with -nomode). It may also be a good idea to RMFaster BASIC. An hourglass %age processed figure is displayed (this may run through twice for some of the more expensive options). The program reads the source image from disc and builds the output in memory, having claimed some from the system. In addition to strictly converting the source image, ChangeFSI can also process it. A trivial option is "-info": ChangeFSI will tell you what it is doing (a good way of finding out what the source image actually is, and how the scaling turns out!). Similarly trivial are -vflip and -hflip - the picture can be produce upside down and left/right reversed. Not so trivial is -rotate, which will rotate the image by 90 degrees (that is, an anti- clockwise quarter turn). -rotate- rotates by -90 degrees (clockwise quarter turn). Sometimes useful is "-nosize": ChangeFSI can read pixel size information from the source image (if present) or guess it (e.g. if there are less than 320 by 256 pixels in a source image, ChangeFSI assumes the pixels are the same size as MODE 13's [45 per inch]) or derive it from other information and scale the output image (composed of RISC OS square or 1:2 sized pixels) appropriately. -nosize stops this from happening. [this seems particularly relevant on formats like TIFF or IFF where the pixel size is specified *but may be wrong*] Using -info will display the pixel ratios which ChangeFSI is using - a combination of the size guess, the output pixel size and any deliberate scaling. "-noscale" turns off the output scaling as well. The simplest image processing option is "-range" which will expand the dynamic range of the input picture so that it fills the available area (not a good option for animated sequences unless all source images possess the same range). Since r, g, b are processed by the same amount, -range preserves the colour of pixels in coloured pictures. A useful option for output intended for the screen only is Gamma correction. CRT displays do not have a simple linear relationship between brightness of the spot and input voltage: instead of brightness = const * voltage, the response is brightness = const * voltage ^ (1/gamma). In the TV industry, gamma has been standardised as 2.2, but there is wide variation in the computer industry: the monitor's response will vary depending on what make it is and how it is adjusted. Low values of gamma (0 to 1) make colours darker and high values (above 1) make colours lighter with the effects being particularly noticeable on dim colours. "-gamma" uses the default of 2.2, and it can be set by "-gamma1.5" say. Gamma correction is most relevant when its known that the input has a linear intensity (input from a scanner or from another computer with more bits per colour component than the Archimedes). A more complex primitive is "-equal" which performs "histogram equalisation" on the image. This makes the histogram of level versus number of points at that level as flat as possible giving full use of the number of colours available. -equal is a very harsh primitive, even on monochrome inputs it can produce an inferior picture; while on colour pictures it can distort the colour of each point (since r, g, b are computed separately). But -equal can often recover a picture that is otherwise completely useless or expose information locked in a small part of the input scale. Image colours may be inverted with the -invert option. Which may be fun in colour but is rarely useful! However, monochrome images frequently need inverting, especially one bit per pixel sources. A more powerful option is "-sharpen" which enhances the edges of objects in the picture: this is very useful since the dithering process inevitably smears information over the display. Pre-sharpening the image can result in a more acceptable output. Default values of sharpening can be overridden for special effects: -sharpen8 does edge detection. Lower amounts of sharpening are obtained with larger -sharpen numbers. In general the more input and output pixels and the greater the output range in a pixel in the images, the less sharpening is required. Sharpening a picture which is already dithered can give a very bad result.... The sharpening is achieved with the following matrix: -1 -1 -1 -1 sharpen -1 -1 -1 -1 ChangeFSI computes the sum of nine pixels with the above weights for each input pixel and renormalises the result (divides by sharpen-8). An option for testing is "-nodither" which disables the Floyd Steinberg error diffusion step completely. Versions after 6th June 1990 are more accurate at doing this. The various processes described above are applied in the following order for pictures with more output pixels than input: (a) range or histogram equalisation, (b) sharpen, (c) scale, (d) error diffusion. This order is chosen so that: (1) since the input pixels (rather than the output pixels) are sharpened, there is no false edge introduced when pixels are replicated. The various processes described above are applied in the following order for pictures with fewer output pixels than input: (a) scale, (b) range or histogram equalisation, (c) sharpen, (d) error diffusion. This order is chosen so that: (1) ranging can enhance down-sized images. Say a black/white dithered image is reduced in size, so that the output from the scaling process is (some approximation to) the original grey levels; then ranging can expand this if possible. (2) sharpening can be used to offset the blurring effects of scaling. (3) since the output pixels (rather than the input pixels) are sharpened, the effect of -sharpenN is consistent over differently scaled images. There may be times when this automatic selection of order gets it wrong, particularly when changing the aspect ratio, it is possible to trigger some undesirable sharpening artifacts. Use the program twice with with sharpening (say) disabled and enabled in the order required. Examples of use: Make "standard palette" versions of existing 256 colour images (for example the Watford digitiser plus colour board doesn't use the standard palette). (e.g. "changefsi in out 13p" for a coloured Watford picture) Or convert a colour picture to something you can see on your high res mono monitor. (e.g. "changefsi in out 18 -sharpen -info") Or convert a large monochrome picture (from a scanner, say) to something which can be seen. (e.g. "changefsi in out 20t 1:4 -gamma") Or convert a colour picture to grey scale for the desktop. (e.g. "changefsi in out 20") Or change a 512 by 480 image to standard format and aspect ratio (e.g. "changefsi in out 15 640:512 512:480") (or "changefsi in out = -range") Or change to digital r, g, b (e.g. "changefsi in out 20d -sharpen16") Or convert a picture for printing on a 300dpi laser. (e.g. "changefsi in out 18c 300:90 -sharpen") And many more uses such as making miniatures of pictures, animated sequences of pictures changing size (or sharpness!), converting Artisan pictures to the desktop (try looking at the Artisan Garden with the desktop in 256 colours and ChangeFSI's version - the stripes on the lawn vanish with the standard version). Obviously you will need to have captured input as a sprite first! Using more pixels per inch can improve the quality of the result, particularly converting to multisync modes. Note that, for all work with ChangeFSI, it is a good idea to start from the unprocessed input each time and do everything in one pass (rather than using the program several times with simple arguments). It is not a good idea to sharpen a dithered image (unless it has been shrunk). *** It is a very good idea to keep the highest resolution master that you can afford the disc space for.... The ChangeFSI program can also convert from non RISC OS sprite formats while doing all of the above processing. ChangeFSI will work out what the format is automatically. For native RISC OS formats, it uses the filetype and there can be no confusion. For alien formats, it first tries looking for particular identifying information inside the file and then (if this fails to have identified a format) tries using the file name itself. See the details below: The RISC OS sprite format Contains 1, 2, 4 or 8 bits per pixel with a modification palette of up to 16 entries; any number of pixels wide and high uncompressed. Details are in Acorn's Programmer's Reference Manual. + Recognised by file type FF9 (a paint brush and house icon) - Details of how many bits per pixel and the pixel size are obtained from the operating system (rather than being in the file) from the "MODE" number. Mode extensions can result in a source image containing a MODE number which your computer does not understand. The ArVis format [of ArVis Multimedia] Contains 5 bits of red, green and blue information encoded into two RISC OS sprites "HIP.<filename>" and "LOP.<filename>" comprising a 640 pixel wide and 256 line tall image with pixels sized 1:2. Details from ArVis Multimedia - Recognised by providing the HIP.<filename> (which must be of file type FF9) - Uncompressed (indeed represents 16 bits instead of 15). The Pineapple colour digitiser format (of Pineapple Software) Contains 6 bits of green, 5 bits of red and blue information filed as a single data file starting "FSIfile" comprising a 512 pixel wide and 256 line tall image with pixels sized 1:2. - Recognised by "FSIfile" in the file (which can be any type) - Uncompressed The Watford Video Digitiser "picture" format Contains a run length encoded 64 grey level 512 pixel wide, 256 line image, with pixels sized 1:2. Details from Watford Electronics Ltd. + Recognised by file type DFA (a small grey picture of Stevie Nicks) - Warning: don't forget to save the pictures in *un-dithered* state! When used with a colour converter, ChangeFSI can read three colour separations stored in a directory of separate "red", "green" and "blue" files. Beware of auto-gain/contrast when using such information! The ProArtisan compressed picture file format Contains a (mildly) compressed MODE 15 (640 by 256 by 256 colours) picture. Details from Clares. + Recognised by file type DE2 (a beige monitor in a grey surround) The TimeStep satellite image format This gives an uncompressed 800 by 800 with 256 grey levels. + Recognised by file type 7A0 (icon never seen) - No resolution specified, equal to mode 27 assumed - Documentation never seen. An extra header file <name>! is not understood at all..... CCIR601 4:2:2 images Contain 720 pixels by 288 rows (PAL) [243 rows NTSC] YUV coded with pixels sized 1:2. + Recognised by file type 601 - one field only Another TimeStep satellite image format Giving an uncompressed 128 pixels wide by 256 lines with 256 grey levels, pixels sized 2:1. Used by TimeStep's !ImProcess application. + Recognised by file type 300 ("i" in a document frame) - Documentation never seen. - A bit coarse The grey levels represent intensity in various different wave bands. By naming files "red", "green" and "blue" and handing ChangeFSI the directory, you can produce a false colour image. Hours of experimentation can produce an almost reasonable picture... The AIM and Wild Vision V10 format This provides an uncompressed 256 by 256 image with 256 grey levels. Details from Delft University of Technology and ECD Computers Delft B.V. + Recognised by file type 004 (a picture of 'Trui' with "TU" in blue) + ChangeFSI can write to this format (specify "aim" in the mode position) and specify = in the sizing to get a 256 by 256 output (otherwise it will be the same size as the source image) - No resolution specified, equal to mode 27 assumed - The associated file <name>+ (file type 010) which contains additional information is ignored by ChangeFSI. The grey levels may represent intensity in various different wave bands. By naming files "red", "green" and "blue" and handing ChangeFSI the directory, you can produce a false colour image. Hours of experimentation can produce an almost reasonable picture... The Wild Vision V12 format This provides an uncompressed 512 by 512 image with 256 grey levels. + Recognised by file type 006 - No resolution specified, equal to mode 27 assumed The Wild Vision V9 and SnapShot formats This provides an uncompressed 512 by 256 image with 4 bits of red, green and blue, pixels sized 1:2. + Recognised by "MercSoft" or "SnapShot" header + No file type needed The !Translator Clear format This provides 1, 2, 4, 8 and 24 bits per pixel. + Recognised by file type 690 - uncompressed, especially for <8 bits per pixel which is recorded at one byte per pixel. - No resolution specified, equal to mode 27 assumed The Atari ST "Degas" format 1, 2 or 4 bits per pixel, clear or run length encoded. RISC OS file type by John Kortink of !Translator. + Recognised by file type 691 - No documentation and only 5 images read - No resolution specified, equal to mode 27 assumed >> All the file formats so far have been designed on RISC OS (or Arthur) and recognition of the format is defined by file type, the files arrive on RISC OS floppy discs, and the originators live in the same time zone. For the following formats many of these things are not true... Which makes it more difficult to guarantee that ChangeFSI will be able to read the file. The Millipede Prisma format (used by CadSoft also) The Millipede Prisma 3 is a 768 pixels wide by 574 line interlaced display board for the Archimedes and BBC Microcomputer. It allows use of 256 colours from 2^24. Files may be stored uncompressed (432KBytes!) or run length encoded. More details from CadSoft or Millipede Electronic Graphics. + Recognised by "MILLIPEDE" at offset 16 in the file - No resolution specified, equal to mode 27 assumed - slowish to read the compressed formats - scaling the picture using = can be poor since 574 lines don't relate very well to 512 or 256. Use -info to display the scale ratios. The Aldus/MicroSoft TIFF format (also filetype FF0 is assigned to TIFF) Frequently used by scanners, TIFF is a common interchange format for graphics images on the Mac and PC (particularly DTP and Windows). It provides an arbitrary number of bits per pixel, size etc using a numeric tag scheme allowing new information to be introduced without upsetting existing programs. The format may be compressed (in 5 different ways at present). Details from Aldus UK, MicroSoft, Hewlett Packard... + Recognised by file type FF0 + Recognised by "II" plus the 16 bit number 42 at the start of the file for little endian machines (ix86, ARM, VAX...) + Recognised by "MM" plus the 16 bit number 42 at the start of the file for big endian machines (M680x0...) + Can read PackBits images and LZW compressed forms (at least the 3 its seen so far...) - Cannot read predictor compressed LZW images. - So far ChangeFSI has only done 1, 4, 8 and 24 bit images. It can't read "planar" images or CCITT compressed forms. - Some TIFF images have incorrect pixel sizes: use -nosize if this is true. If no pixel size is specified, ChangeFSI assumes mode 27 size. The CompuServe GIF format Used for wide area network transfer of images. It provides an LZW compressed up to 256 colours from 2^24 arbitrary sized image. Details from CompuServe (USA) [or usenet] + Recognised by "GIF87a" at the start of the file + LZW compression is efficient even for dithered images + ChangeFSI can decompress LZW quickly - No resolution specified, equal to mode 27 assumed - many low quality images around from PCs The Electronic Arts IFF ILBM format Provides an arbitrary sized image with up to 4096 colours sometimes run length encoded. ChangeFSI understands the generic format and also the special Amiga format for "HAM" and "Half-bright" images. + Recognised by "FORM" as the first four characters and "ILBM" as characters 8 to 11 - Only pixel aspect ratio specified, not its size (and then sometimes incorrectly): use -nosize *and* a size change (a:b) if its wrong - images often small - doesn't understand Amiga "hires" - can't convert HAM pictures directly to monochrome The MicroSoft Windows 3 .BMP format Used by MicroSoft in Windows 3 and PaintBrush for Windows 3. Provides an arbitrary sized image and 1, 4 or 8 bits per pixel. Uncompressed. + Recognised by "BM" as the first two characters - No resolution specified, equal to mode 27 assumed - documentation never seen - 7 files examined and intelligent guesses made! The Digital Research GEM .IMG format Used by GEM (and GEM Paint) on both PC and Atari ST. Provides an arbitrary sized image and number of bits per pixel (though its only usually used with up to 5 bits per pixel) and pixel size. Compressed by run length encoding and line repeats. - Recognised by 00 01 00 08 as the first four bytes ("version 1, header length 8") or by "IMG" as the name of the directory the file is in. - Planar file format slow to read - Palette not specified: ChangeFSI assumes linear shades of grey. You might need to use -invert if the image is a negative - The size of a pixel is specified in microns. The standard RISC OS 90 pixels per inch translates to (1/90*2.54*10,000) microns - 282. (use -info to get information about the scaling, -nosize to stop it) - Documentation from the "ST World" magazine's clinic. An unknown PC .PIC format Used for some VGA demos, the format provides an uncompressed 320 by 200 by 256 colour (from 2^24) VGA screen dump. + Recognised by "AV_VO" as the first five bytes in the file - Documentation never seen - Pixel size assumed the same as MODE 13 (45 pixels per inch). The MacPaint format Provides a 576 by 720 bitmap, run length coded by the Mac's "PackBits" algorithm (repeated bytes). - Recognised by "PNTG" at position 65 in the file. This may only relate to files which have been through a program called "MacFix". Data assumed to start at position 128 in the file. Header ignored. - No resolution specified, equal to mode 25 assumed The ZSoft .PCX format Used by PC Paintbrush. Usually a 4 bit per pixel image (CGA, EGA, VGA) but can be 1-8 bits per pixel. - Recognised by 10,[0,2,3,4,5],1 at start of file. Or by name PCX.<foo> + Intelligent check for resolution of the DACs on the PC card. Use -info to find out what ChangeFSI thinks it is. + Pixel size information read. You may need to stop the scaling with -nosize, since its often wrong. The RIX Softworks ColoRIX format Used by VGA Paint, image extension .SCE .. .SCX. 4 or 8 bits per pixel. - Recognised by "RIX3" at start of file - Documentation never seen - Only 5 files read: ChangeFSI checks to see if the header is the same as these files and complains otherwise. - No resolution specified, equal to mode 27 assumed The Sun "pixrect" format Used under SunOS and also under X11. Commonly 1 or 8 bits per pixel, but up to 24 bits per pixel can be found (see the Sun NeWS release tape!). + Recognised by &59A55A95 at the start of the file. - No resolution specified, equal to mode 27 assumed - Sun didn't specify the pixel ordering of 24 bit per pixel images: many assume RGB when it was actually BGR. Change byte &17 in the Sun rasterfile between 1 and 3 if you have a problem. The "pbm" 'portable bitmap' file format Used by the "PBM-PLUS" toolkit (mainly Unix) by Jef Poskanzer. 1-24 bits per pixel (more can be specified in the format but ChangeFSI cannot read them). ChangeFSI can only read the "RAWBITS" formats (it can write all of the pbm formats). + Recognised by P4/P5/P6 at start of file. + Writable by ChangeFSI - No resolution specified, equal to mode 27 assumed The UNIX "rle" format Used by a program called "svfb" to save the contents of large frame buffers, checked with four images at 24 bits per pixel. + Recognised by &CC52 at the start of the file. - No resolution specified, equal to mode 27 assumed The TrueVision Targa format Used by TrueVision for Vista boards. Up to 32 bits per pixel. - Recognised by suffix _TGA or _VDA on the name. - Only uncompressed formats readable. - Only 8 and 16 bit per pixel formats tested. The "Flexible Image Transport System" (FITS) format Used for astronomical data. Up to 16 bits per pixel component. + Recognised by "SIMPLE" at the start of the file. - Only 8 and 16 bit per pixel component formats tested. - Only two files ever seen! - No resolution specified, equal to mode 27 assumed The Irlam instruments colour scanner format 24 bit per pixel from colour scanner. + Recognised by Irlam 24 at the start of the file. + Writable by ChangeFSI - No resolution specified, equal to mode 27 assumed - may need gamma correction The Irlam instruments YUV 411 colour video format 7 bits Y, up to 7 bits U and V. + Recognised by Irlam YUV 411 at the start of the file - no resolution specified, equal to mode 27 assumed The JPEG 'JFIF' File Interchange Format Up to 24 bits R,G,B, compressed by the JPEG compression system. + Recognised by JFIF at position 6 in the file (you may have to cut headers off files, particularly oif they are from Macs). + Often highly compressed - ... and therefore slow. Needs a lot of space in <Wimp$Scrap>. - ChangeFSI calls a djpeg routine. This can be on the Run$Path, implemented as an Alias (in which case it *must* use WimpTask to start) or found inside ChangeFSI$Dir if all else fails. cjpeg (the compressor) is also available inside ChangeFSI$Dir - you will need to convert the image to P6 format before it can be compressed. Djpeg and cjpeg are by the PD JPEG group. - no resolution specified, equal to mode 27 assumed >> The following file formats are only recognised by their names. An unknown PC .DSP format Experimentally determined that it holds a 640 by 350 EGA picture at 4 bits per pixel. ChangeFSI "knows" the default EGA palette (from IBM literature). - Recognised by being in a directory "DSP" - Documentation never seen - No resolution specified, equal to mode 27 assumed - Only two examples read(!) The QRT .raw format Output from Steve Koren's public domain ray tracer: arbitrary size in 2^24 colours, uncompressed. Documentation part of QRT. - Recognised by the name ending ".Raw" - No resolution specified, equal to mode 27 assumed The MTV pic. format Output from Mark Terrence VandeWettering public domain ray tracer arbitrary size in 2^24 colours, uncompressed. Documentation part of MTV. Also used by "RayShade". - Recognised by being in a directory "Pic." - No resolution specified, equal to mode 27 assumed The RT image. format Output from "RT", a private ray tracer by Brian D Watt(?) arbitrary size in 2^24 colours, run length encoded. - Recognised by being in a directory "Image." - No resolution specified, equal to mode 27 assumed For many of these formats, especially the uncompressed ones, setting the variable "ChangeFSI$Cache" to the number of bytes of temporary memory you wish the program to use will speed up reading the information. The default is 8192 bytes. For example "*set ChangeFSI$Cache 40k". For those worried about speed, the program will go faster if: - you use -noscale and keep 1:1 ratios (don't specify them) (although -nosize and 1:1 or 1:2 ratios are quick, too) - you don't need sharpening, histogram equalisation, range expansion - you use monochrome (e.g. 25, 26, 27 and 27t) modes additionally you can disable dithering (-nodither) especially when reading monochrome source. You can avoid the program changing mode by putting -nomode on the command line. Very large output files can be built strips at a time and sent directly to disk using the parameter "-max" e.g: ChangeFSI <in> <out> 28 -max512K will convert the file with a maximum of 512KBytes held in memory. Options 25t, -rotate and -vflip don't work when this is being done. Work will be done on other formats when and if both image and documentation arrive on my desk. Adding a new format is a matter of (a) putting in automatic recognition of the format at the start of the program (b) reading the size of the image and the colour palette mapping [in the next section of the program] (c) writing a "read pixel row" element inside PROCiprow (d) providing an entry in PROCrewind. If you write a new format interface, please send it to me so that it will be included in later versions. ChangeFSI has already got code for dealing with images with 1, 2, 4 and 8 bits per pixel packed into bytes and for images with up to 8 bit planes. There is support code for LZW decompression and LZW decoding. As a special feature, ChangeFSI will also write out 256 grey level files (alter rwt, gwt and bwt to get 256 level colour separations) in AIM format. This is file type 4 with bytes representing the grey level. Use the = operation to restrict the picture to 256x256y, otherwise it will be the same size as the input. Specify "aim" as the mode string to do this. For portability to other machines, ChangeFSI can write out files in "pbm" format. There are 3 types of format "black/white" (pbm), "grey" (pgm) and "colour" (ppm) with pure ASCII and binary encodings of each: ASCII Binary p1 "black/white" (like mode 18) p4 (big endian bytes!) p2 "grey" (like mode 20t) p5 p3 "true colour" p6 Files can be read with Jef Poskanzer's portable toolkit on other machines. The p2 format is easily convertible by programmers; it consists of: P2 # comment line xsize ysize maximum_value pixel_value <whitespace> pixel_value where all the numbers are in decimal (ASCII). 0 means black, maximum_value (= 15) means white. The p3 format is similar with r, g, b triples for each pixel value. The number of bits per component (default 8) can be set from the command line with, for example, "p3,4" for 4 bits per component. As a special packed output format, "P15" has been implemented. Output is binary pixel values, 5 bits per component, little endian RGB order packed into 16 bits. Header information as the other p formats. ChangeFSI can write Irlam format images (somewhat slower than p6 images...). Output summary ============== # cols Colour Cube Bits used Consistent Hue Desktop Palette Mode&Suffix 2^24 Y 24 Y - p3 or p6 or Irlam 2^21 Y 21 Y - p6,7 2^18 Y 18 Y - p6,6 2^15 Y 15 Y - p15 or p6,5 2^12 Y 12 Y - p6,4 512 Y 9 Y - p6,3 256 grey n 8 Y - aim 256 grey n 8 Y - 28d 256 Y 8 Y Y 28 256 Y 8 Y Y 28t 256 Y 8 Y Y 28r 16 grey n 4 Y n 27t 16 grey n 4 Y n p2 or p5 8 grey n 3 Y Y 27 16 ? 4 ? Y 27r 16 Y 3 Y can be 27d 4 grey n 2 Y Y 26 4 n 2 n n 26c 4 n 2 n n 26r 2 (black/white) n 1 Y Y 25 2 (black/white) n 1 Y Y 25c/d/t 2 (black/white) n 1 Y Y p1 or p4 ChangeFSI can be used from both the desktop front end and from the command line. It can also be used as a BASIC library function: LIBRARY"<ChangeFSI$Dir>.ChangeFSI" gives a new function, FNChangeFSI to the BASIC programmer. This function takes: A$: a command line argument spritearea%: an address or -1 for the spritearea built by ChangeFSI workspace%: an address or -1 for ChangeFSI's other workspace worklimit%: an address (unused if workspace%<0) fast%: TRUE for MODE 0 selection It produces an error (to whatever error handler is present) if it fails. If spritearea% is <0 it will save the sprite to the file given in the command string, otherwise it won't. The function FNChangeFSIVersion returns the version string of the library (in the info box of the desktop application). Command Summary =============== -info give details -hist don't process image, but display histogram of it instead -hflip horizontally flip the image -vflip vertically flip the image -rotate rotate the image by +90 degrees (i.e. anti-clockwise) -rotate- rotate the image by -90 degrees (i.e. clockwise) -max set the maximum size of the image before disc is used -noscale disable automatic pixel size correction -nosize disable automatic pixel size correction for input pixels only -nodither disable dithering -nomode don't change to mode 0 while processing the picture -invert invert colour range of image -range expand input's dynamic range to full scale -equal histogram equalisation -sharpen digitally sharpen the picture -gamma set gamma correction -black correct for black ink spot size -red change red weight for deriving monochrome luminance -green change green weight for deriving monochrome luminance -blue change blue weight for deriving monochrome luminance -brighten horrendous hack to slightly brighten images: may convert hues close to white to white. (It causes the output range 0..15 to be considered as 0..(15/16) instead of 0..(15/15)). Mode Suffixes ============= c 1 bit modes: use clustered dithering with 4x4 cell 2 bit modes: use the four colours "black", "cyan", "magenta" and "yellow" d 1 bit modes: use clustered dithering with 2x2 cell 4 bit modes: use 1 bit red, 1 bit green, 1 bit blue 8 bit modes: use 256 level grey scale t 1 bit modes: use clustered dithering with 3x3 cell 4 bit modes: 16 level grey scale 8 bit modes: use table driven selection r 2 bit modes: Roger Wilson's (me) colour matching algorithm 4 bit modes: Roger Wilson's (me) colour matching algorithm 8 bit modes: Roger Wilson's (me) colour matching algorithm (SLOW!) -no suffix- 1 bit modes: b/w dispersed dot dithering 2 bit modes: 4 level grey scale 4 bit modes: 8 level grey scale 8 bit modes: John Bowler's colour matching algorithm Colour matching is done in r, g, b space: the minimum distance between colours is the square root of: delta_r^2*rmatchwt+delta_g^2*gmatchwt+delta_b^2*bmatchwt ChangeFSI has hard wired weights of 3, 10, 1 respectively for its colour matching algorithms. John Bowler's algorithm (default for RISC OS 8 bit modes) although somewhat slower, is fast enough to have replaced all the previous methods [ASIDE it gives pictures at least as good as "p" mode in pre Aug 91 ChangeFSI's]. Roger Wilson's (i.e. my) colour matching algorithm is too slow in 8 bit modes to be recommended, but it is used automatically if the PCATS Graphics Enhancer is in use: the colour set for output is not the RISC OS colour set. [NOTE: thanks are due to Steve Green and the BBC and Irlam Instruments for the intermediate systems that led to John Bowler's and my algorithms: until Aug 91 ChangeFSI used their work for its "Precise Matching" algorithm. It no longer uses any of their code, but owes a debt for overall approach.] The 8 bit mode t algorithm requires a 4096 entry lookup table indexed by 4 bits of r, g, b information with r as the bottom 4 bits, g as the next 4, b as the top 4 bits. The table yields a byte which is the colour to use. Immediately following this table are 256 32 bit words of form BBGGRRxx which give the outputs for each input colour. The program loads the table as <ChangeFSI$Dir>.CFSIict. Further information on dithering can be found in "Digital Halftoning" by Robert Ulichney published by the MIT Press, ISBN 0-262-21009-6. A book which I wish I'd had when I started writing the program, rather than after it was nearly finished! Histogram equalisation is in "Algorithms for Graphics and Image Processing" by Theo Pavlidis published by Computer Science Press, ISBN 0-914894-65-X.